Most operating systems (OSs) default behavior for authorization of peripheral devices (interfaced to a host device having the OSs) are to present popup windows for the users to accept or decline permission for access to the peripherals upon host device connection.
This can be unacceptable for an unattended operation (an operation processing when no user is present to accept or decline the OS-presented accept or deny request (permission) of the popup window). Such a situation could prevent the host device from automatically starting an application, which may be needed for the host device before starting that application.
Moreover, in many cases the user permission needs to be renewed after application installation. So, even if permission was granted (during a user-attended situation to provide peripheral permission) and the application is executing normally on the host device, if the application is subsequently upgraded/updated (which could occur automatically by the OS when the user is not present) then the issue resurfaces on the upgrade/update of the application when the user is not present to provide the needed OS permission.
There are also general concerns around the connection of unauthorized peripheral devices being connected to a host device/host system, such as:
1) security because connecting unauthorized hardware may be an attempt to get the OS to automatically perform some unauthorized action on the host device (such installation of spyware, malware, etc.); and
2) parts protection because some secure host devices/systems may only authorize peripherals from known vendors, such that the secure device/system: may operate improperly with other vendor products, may expose security holes, and may be detrimental to the products and reputation of the known vendors.